\subsubsection{Comparacion ASM vs C}
    \includegraphics[width=140mm]{halftone.png}
    
Para este filtro vemos que si bien parece que la curva de Asm creci\'on en mayor magnitud comparado con Recortar, en realidad no, porque la escala cambi\'o. Si bien para este filtro por cada bloque de 2x2 pixels es necesario hacer comparativas y sumarlos, cuya suma no entra en un 1 bytes y eso nos fuerza a usar mas espacio para procesar pixels que en consecuencia implica menos pixels procesadores simultaneamente por iteraci\'on, a\'un podemos ver una menor cantidad de ticks de ejecuci\'on que en Recortar.\\
Por qu\'e? \\
La respuesta est\'a en que estamos procesando de a dos filas por cada iteraci\'on, de modo que es esperable que dicho tiempo de ejecuci\'on este alrededor de la mitad que lo que tom\'o Recortar. \\
Halftone tomo poco mas de 1 mill\'on de ticks y Recortar aproximadamente 2 millones.

\subsubsection{Speedup}
    \includegraphics[width=140mm]{halftone_speedup.png}

En este gr\'afico, a diferencia del speedup anterior, se puede notar que no se est\'an procesando 16 pixels por iteraci\'on pu\'es el speedup es menor, de hecho, esta alrededor de 7, que es muy cercano a 8, que es el n\'umero de pixels que realmente procesamos por iteraci\'on.\\
Notar que cuando analizamos el speedup, nos basamos siempre en el peor caso, o sea, en la menor brecha de diferencia de ticks entre la implementaci\'on en C y la de ASM. Sabemos que la implementaci\'on en ASM puede tener picos de mayor velocidad pero eso se debe a la ejecuci\'on en particular en la que se tom\'o la medici\'on, de modo que para poder hablar de un comportamiento o un patr\'on de performance, nos basamos siempre en el peor caso.
